A network switch is a hardware device for making and breaking a data connection between two endpoints. Switches may be employed to crate a virtual circuit between pairs of endpoints, fulfilling a role similar to that of a router in a connectionless network by diverting data packets toward their intended destination.
Switches traditionally have two software planes: a control plane and a data plane. The control plane is the portion of the system responsible for providing the actual functions and features of the system. The data plane is responsible for actually sending and receiving data to and from the ports that connect the switch to the outside world. In some cases, separate processors (“network processors”) can also control these ports. From a purely architectural standpoint, the separation between the control plane and the data plane into different processors is system dependent, and may also be carried out in the operating system used on the switch.
Many prior art switches follow this separation of control plane and data plane. In order to facilitate the software specifically designed for the control plane, Application Programming Interfaces (APIs) have been utilized by additional software added to the control plane to interact with the data plane. These APIs are collectively referred to as the Hardware Abstraction Layer API (HAL API).
Local Area Network (LAN) technologies typically differentiate between switching functions and routing functions. Switching functions involve the transport of packets from a source port to a destination port using a Media Access Control (MAC) address of the Ethernet frame that encapsulates the data packet. These switches are often referred to as hubs. Routing, on the other hand, involves basing forwarding decisions based on an Internet Protocol (IP) address that is assigned to a computer. The Ethernet frame then encapsulates the IP packet and the IP address of the source and destination end-points. As a result, it takes longer to resolve packet destinations in a router than it does in a switch because the Ethernet frame has to be stripped out before the IP packet is processed.
Modern switching and routing systems may actually be combined to allow either switching of Ethernet frames based on the MAC address or the IP address. These capabilities are now embodied into the actual network processors used in the switching systems that control the ports of the system. Hence, new capabilities need to be added to the data plane to facilitate this new state-of-the-art combined functionality. Additionally, Virtual LANs enable the creation of virtual network topologies within the physical topology of the LAN. This enables the separation of data flows within the LAN using the same Ethernet physical links. From a topology perspective, the physical LAN topology and the Virtual LAN segments represent different Virtual LANs that are virtually independent, hence improving security.
The main drawback of these systems, however, comes in their design stage. Designers must implement the following components:
1. A mechanism for interfacing the routing and interface management with the control plane.
2. A mechanism to propagate configuration and logging functions from the control plane to the data plane.
3. A packet driver for control packet handling (a layer to intercept packets from the hardware components before they are passed to the data plane's IP forwarder/routing stack).
4. An exception packet handler (to capture control packets communicating topology information that the IP routing stack does not know how to handle, examine them, and forward them to an appropriate L2 protocol for further processing).
5. An interface manager layer (to facilitate the creation, handling, and management of virtual interfaces and maintain the bindings between virtual ports and physical ports, as well as handle the creation and management of aggregated physical ports into a virtual aggregated ports, the distribution of packets between these virtual ports, and maintain the administrative status of the virtual and physical port).
6. A component to mirror functions between the Hardware Abstraction Layer and the Hardware Integration Plane (to extend the HAL APIs to the data plane and provide a hardware based PI to interface to the actual hardware driver's APIs).
7. A software shim layer between the HIP API and the hardware driver's APIs (in the data plane) to translate the HIP API to the driver's APIs.
8. Chassis and stacking support, including a reliable data transport mechanism and a discovery mechanism.
9. Extending a management interface layer from the control plane into the data plane.
Placing this much burden on the designers of a switch increases their development costs as well as development time. Traditionally, these functions are performed ad-hoc without any consideration as to the interrelationships between the abstracted functions, in many cases creating unnecessary duplication of functions, data structures, and communication paths. Additionally, many times switch software is distributed to customers who need to customize them to work with their own hardware. Thus, the design burden for all of these components is placed on the customer. What is needed is a solution that does not require designers or customers to engage in such time consuming development.